[レポート]『OpsJAWS Meetup#25 インシデント管理』に参加しました #opsjaws #jawsug

みなさん、こんにちは。

明るい笑顔がトレードマーク、ルイボスティーが大好きな芦沢(＠ashi_ssan)です。

2023/9/4に開催された【ハイブリッド開催 】OpsJAWS Meetup#25 インシデント管理 - OpsJAWS | Doorkeeperに参加しました。

参加するだけではもったいないので、本記事で聴講したセッションのレポートを書いていきます。

セッション① Incident Manager を使って実現するインシデント管理

登壇者

アマゾン ウェブ サービス ジャパン合同会社 上野 涼平 様

登壇資料

セッション3行まとめ

• インシデントとは、計画外のサービス停止やサービス品質の低下をもたらすもので、早急な復旧が求められるもの。
• Systems Manager Incident Managerを利用することで、インシデント発生時のアラート通知(電話、Email、SMS)やエスカレーションスケジュールの管理などコミュニケーションが統合的に管理できる。
• 活用ユースケースはさまざま。ベーシックなCW Alarmをトリガーにするインシデント管理アーキテクチャ以外にも、一部機能だけ(電話通知だけ、Slack通知周りだけ)使うというやり方もあり。

質疑応答

• Q. 連絡先の登録はまとめてアップロードできますか？コンソール上からだと大変そう。
  • A. API経由なら可能かもだが、対応していなさそう。
• Q. 外部のチケット管理システムに直接連携は可能か？
  • A. Jira(Jira Cloud、Jira Service Management)だったら一部連携可能。
    • その他対応サービスが参考ドキュメントに記載されています。
    • 参考: インシデントマネージャーとの製品とサービスの統合 - Incident Manager
• Q. Connectとの連携は可能？
  • A. ネイティブな統合は非対応だが、頑張ったらできるかも。
• Q. オンコールスケジュールの外部スケジュールサービス連携はできるか？
  • A. 今のところ非対応。
• Q. 短時間に一度に複数のアラートを検知した時の挙動は？インシデントのまとめなどは可能？
  • A. トリガーする側のサービスの機能に依存する（CloudWatchアラームなど）ので、アラートをまとめたい場合は、そちら側でハンドリングしてね！

感想

何となくIncident Managerは使いづらいイメージがあり今までの提案にも導入するケースに出会ってきませんでした。

このセッションでインシデント管理に必要な各種機能を持っていることがわかったので、今後は部分的な利用の提案からでも提案していけると良いな、と感じました。

セッション② インシデント対応の成熟度とベストプラクティス

登壇者

PagerDuty株式会社 Solutions Consultant 山田 索 様

登壇資料

セッション3行まとめ

• PagerDutyはインシデントをより早く少ないリソースで解決し、将来のインシデントを未然に防ぐことを目的としたソリューションを提供するサービス。
• インシデント管理のベストプラクティス集(無料)とベストプラクティスを実践するためのソリューション(有料)、その２つのセットのサービス。
• ソリューションにあるAIOps/Automation機能を利用すると、アラートのノイズ削減、コンテクストの提示、運用作業を自動化できる。

感想

ベストプラクティスの暗黙の原則『エンジニアは貴重なリソース。大事に扱う。』は何度でも声に出して読みたくなりました。

直前のセッションのSSM Incident Managerと比べると、AI利用や対応の自動化によりインシデント管理をより最適化させられるたサービスだな、と改めて感じました。

SaaSのソリューションのみの提供ではなく、インシデント対応ができる作るための無料のベストプラクティスとセットでサービスが考えられていて素晴らしいな、と思いました。

質疑応答

• Q. インシデント対応の自動対応ではPagerDuty自身からAWSのAPIを実行可能か？
  • A. 可能です。
• Q. AI機能の学習機能はユーザーごとのテナントに閉じているか？
  • A. ユーザーごとのテナントに閉じている
• Q. 学習・予防機能は具体的にどんなもの？
  • A. サービスごとのSeverityに応じてMTTR、MTTAを計測し、それに応じた推奨事項が出力される。例えば、3回回っているから、など。
• Q. 生成系AIでのインシデント提供でシステムが破壊されないか？
  • A. 現在はそのまま出力するのではなく、人がチェックが挟まれているので問題ない。

セッション③ みんなが幸せなインシデント管理

登壇者

OpsJAWS運営 吉井亮 様

登壇資料

セッション3行(+α)まとめ

• 特に偉い人に聞いてほしいセッション。
• この会を企画した理由は「IncidentManagerを取り上げたかったから」「アンケートの開催要望として上がっていたから」
• インシデント管理で不幸が発生する箇所のまとめ
  • 「アラート疲れ」：なんかアラート発生してるよ、はやめてほしい
  • SLOを比較：稼働率と比べてほしい
  • 手順書がない：まずはサービス回復から、エスカレーションも手順の1つ
  • 引き継ぎが大事：ライブインシデント状況ドキュメントが大事。引き継ぎは対面で
  • ヒーローはいらない：つよつよエンジニアだよりは不幸になる。
  • インシデントの繰り返し：根本対策、早くやろう！
  • 対応するのは人間：小さい子供が生まれたらインシデント対応から離れることをみんなで許す。持ち回りの公平化
  • 訓練：初めての時はシャドウイングから。研修が大事。
  • お金：オンコール対応したらお金。何もしなくても当番ならお金。

感想

吉井さんの過去の苦しみがひしひしと伝わるLTでした。

抽象的なベストプラクティス形式ではなく、具体的な運用のイメージが湧くサンプルでアンチパターンが紹介されていたので、偉い人にもまっすぐに伝わりそう。

今エンジニアが不幸になるオンコールで苦しんでる方々（だけじゃなく、上司や会社の経営層の方々）に伝わってほしい。

最後に

本エントリでは、OpsJAWS Meetup#25 インシデント管理の参加レポートをまとめました。

ご参考になれば幸いです。

以上、芦沢(＠ashi_ssan)でした。